The proliferation of cloud based services and systems continues to increase. Specifically, cloud-based content management services and platforms have impacted the way personal and corporate electronically stored information objects (e.g., files, images, videos, etc.) are stored, and has also impacted the way such personal and corporate content is shared and managed. One benefit of using such cloud-based platforms is the ability to securely share content among trusted collaborators who access shared content on a variety of user devices such as mobile phones, tablets, laptop computers, desktop computers, and/or other devices. Certain cloud-based shared content management platforms might further partition the shared content to improve access performance (e.g., using partitioned index files and partitioned shared content) so as achieve a particular degree of access and retrieval performance.
In some cases, an index might designate certain locations (e.g., physical and/or logical server location) for corresponding instances of shared content. For example, content that is controlled (e.g., owned) by a given enterprise might be purposefully located at a storage site that is near a majority of the enterprise users. The content index tables used to locate and access the controlled content can also be partitioned based on a geographical co-location technique, or on based on a computing platform size, or on the basis of a quanta of data (e.g., a certain number of files), or in accordance with any other regime. One such partitioning technique is called “sharding”. One possible sharding operation serves to partition a database table horizontally (e.g., by row) to form a “shard” that can be located (e.g., in a particular geography or on a particular computing platform) so as to improve performance (e.g., access latency).
For example, a database table comprising an index to all content managed by a cloud-based shared content management platform might be sharded by, for example, an enterprise name. Content controlled by a particular enterprise would be stored on a computing platform that is located near the respective enterprise content. Such co-location of content and content index shards can improve the performance of access to controlled content. Unfortunately, the foregoing partitioning and/or sharding techniques can be limited at least in their performance (e.g., latency) pertaining to accessing content that is shared with a given user, group and/or enterprise. Specifically, while content and/or content indexes might be partitioned, the collaboration attributes defining shared content access (e.g., permissions, relationships to associated user-collaborators, content type, etc.) might still be centralized in one database table and/or location. In this case, for example, a user collaborating on a certain shared content object (e.g., file, folder, etc.) from another enterprise might need to query (e.g., for access permissions, shared content object ID, etc.) a centralized collaboration attribute table that can be in a location that is suboptimal as pertaining to access latency. In legacy deployments, such as un-sharded (e.g., centralized) deployments, some or all of the stored centralized attribute tables might need to be searched in order to access the shared content object. Further, a corresponding set of collaboration attributes pertaining to the shared content (e.g., permissions, etc.) might need to be accessed, possibly from a location that is geographically distant from the storage location of the shared content. Such accesses (e.g., to retrieve collaboration attributes) often detract from, or eliminate the gains that might have accrued by sharding the shared content. This problem is increasingly exacerbated as the number of collaborators increases. What is needed is a technique or techniques to improve over legacy approaches.